這篇的兩個案例都經過去識別化處理

以下兩個案例來自實際的顧問經驗，為保護客戶機密，人名、機構名稱、系統細節皆已去識別化改寫，僅保留架構審查方法論本身具有參考價值的部分。

案例一：金融業的 AI Guardrail 架構審查

某金融機構在導入生成式 AI 客服系統前，委託進行架構安全審查。審查過程中發現的共通模式，跟這系列前面幾週談的內容高度呼應：

發現一：Service Account 權限分層不足。 呼應 Day7——多個不同用途的 AI 功能（客服應答、內部知識檢索、報表生成）共用同一組憑證，一旦其中一個功能的呼叫端點被入侵，衝擊範圍會直接擴及所有功能。

發現二：資料邊界模糊。 呼應 Day13、Day15——訓練資料與生產推論資料放在同一個沒有服務邊界圈定的專案下，且未對訓練資料執行過 Sensitive Data Protection 掃描。

審查方法論：架構審查不是列一份缺失清單就結束，而是把每個發現對應回具體的技術控制建議（例如「權限分層不足」對應到「依 Day7 的職能拆分原則重新設計 Service Account 架構」），讓客戶拿到的不只是問題清單，而是一份可執行的補強路徑圖。

案例二：醫療業的 AI 治理框架落地挑戰

另一個醫療機構的案例，挑戰點不在技術本身，而在治理流程：技術團隊已經正確設定了不少安全控制，但缺乏一套機制去持續驗證這些控制「有沒有隨著時間被繞過或退化」——例如一開始設定好的 VPC Service Controls 邊界，半年後因為新專案上線，被開了一個未經審查的例外規則。

核心啟示：技術控制設對了只是起點，治理挑戰在於建立持續驗證的節奏，而不是把架構審查當成一次性專案。這也是 Day25 SCC、Day26 Google SecOps 存在的意義——沒有持續的可觀測性，任何架構審查的成果都會隨時間自然流失。

兩個案例的共通方法論

兩個案例都指向同一個結論：架構審查的價值不在找出多少個問題，而在把問題轉譯成具體、可執行、可持續驗證的技術控制。這也是這系列 30 篇文章從一開始的設計初衷——每一篇都不只是介紹一個 GCP 服務，而是回答「這個服務具體解決了哪個治理缺口」。

這篇的檢查清單

• [ ] 是否已對照案例一的兩個發現，檢視自己的 AI 系統是否有相同的權限分層與資料邊界問題？
• [ ] 是否已建立機制，持續驗證既有安全控制沒有隨時間被繞過或退化？
• [ ] 架構審查的產出是否轉譯成具體可執行的技術控制建議，而非只是問題清單？